大家好，昨天我們聊了歐盟 AI 法案中最嚴格的兩個等級（禁止和高風險），也探討了法案透過「布魯塞爾效應」對我們台灣開發者產生的實質影響。

今天我們來把下半部分啃完：包括有限風險、最小風險的定義，通用 AI 模型（GPAI）的特殊規則，以及在實務開發上最關鍵的「責任劃分與合規步驟」。

在台灣，如果你們公司的產品有串接 AI 聊天機器人，或是用 AI 幫客戶生成圖片和影片，今天的「透明度義務」與「角色職責」就是你的合規重點！

一、 有限風險（Limited Risk）—— 告知與透明度

有限風險的 AI 系統不需要像高風險那樣做嚴格的安全評估，但它有一個最核心的要求：透明度義務（Transparency Obligations）。

簡單說，就是「必須老實告知，不能裝成人類」：

1. AI 聊天機器人（Chatbot）：當使用者在網站上跟客服機器人對話時，系統必須在開頭明確告知：「您目前正在與 AI 客服互動。」
2. AI 生成內容（Deepfake/AIGC）：用 AI 畫的圖、生成的音樂或合成的影片，必須在畫面上標記「此內容由 AI 生成」，防止假新聞或詐騙傳播。
   • 技術實踐：在實務上，這通常是透過在檔案中嵌入浮水印（Watermarking），或者是在圖片/影音的 Metadata（元資料） 裡塞入符合業界標準（如 C2PA 協議）的安全簽章來實現。
3. 情緒辨識系統（非工作/教育場景）：例如客服中心分析客戶聲音中的情緒以改進服務，雖然這在工作場所是被禁用的，但在一般商業客服是允許的，但必須事先告知使用者。

二、 最小風險（Minimal Risk）—— 幾乎不管制

這類 AI 佔了市面上絕大比例的應用，歐盟幾乎完全不管制，大家可以放心開發：

• 垃圾郵件過濾器：像是伺服器自動幫你擋垃圾信的 AI。
• 推薦系統：像是影音平台推薦你歌單或影集的 AI。
• 遊戲 AI：電玩裡陪你打怪、對戰的 AI 敵人。
• 文法檢查工具：幫你修改英文錯字的自動校正 AI。

三、 通用 AI 模型（GPAI Models）的特殊規則與責任轉移

法案還針對 GPAI（General Purpose AI，通用 AI 模型） 制定了特殊規則。
這主要是指像 OpenAI 的 GPT 系列、Anthropic 的 Claude，或是 Google 的 Gemini 這類大語言模型。

1. 為什麼要單獨管它們？

因為這些大模型就像是「萬用建材」。開發大模型的廠商，根本不知道下游的軟體公司會把模型拿去幹嘛。所以，歐盟要求大模型廠商必須做好「源頭管理」：

• 公開訓練資料摘要：你用了哪些網站、哪些版權書來訓練 AI？必須公開（這跟著作權法息息相關）。
• 技術文件與說明書：說明模型是怎麼訓練的，以及它的限制在哪裡。

2. 系統性風險通用 AI（GPAI models with systemic risk）

如果模型的訓練累計算力超過了 $10^{25}$ FLOPS（這是一個超級龐大的運算量），就會被定義為具有系統性風險的模型（通常是巨頭的旗艦模型）：

• 必須主動向歐盟 AI Office 申報。
• 必須進行對抗性測試與紅隊評估（AI Red Teaming）。
• 必須建立嚴重安全事故的通報機制。

💡 自學筆記：Provider（提供者）與 Deployer（部署者）的責任甩鍋戰
這是在準備 GRC（治理、風險與合規）時，我覺得對我們寫系統接專案的人來說最重要的一個觀念：責任是會隨著「預期用途（Intended Purpose）」的改變而轉移的！
法案把角色分得很清楚：

• 提供者（Provider）：開發 AI 大模型的廠商（例如 OpenAI）。
• 部署者（Deployer）：把 AI 拿來用在自家業務、或開發成系統給終端用戶使用的企業（例如我們與客戶）。

這裡有個超級大坑：如果我們今天高高興興串接了 OpenAI 的 API，幫客戶開發了一款軟體，結果客戶把這款軟體拿去「篩選履歷（這是就業管理，屬於高風險 AI）」。
這時候，OpenAI 只算 Provider，他們只要提供說明書和技術文件就拍拍屁股沒事了；而我們和客戶作為 Deployer，居然要一肩扛起「建立高風險風險管理系統」、「資料品質治理」和「人工監督一鍵推翻」的全部嚴格合規義務！
所以，身為資深系統分析師，在跟客戶接案、開規格書時，一定要看清楚客戶的 AI 預期用途（Intended Purpose），並在合約中寫清楚合規責任歸屬，不然到時候被罰 3% 年營收，我們小公司根本賠不起！

四、 企業 AI 合規落地的四大步驟

如果公司目前正在引進或開發 AI 應用，建議按照這四個步驟來安排合規路線：

企業 AI 合規四大步驟

【步驟一：AI 盤點 (Inventory)】
   ──→ 盤點公司內部到底用了哪些 AI 軟體、API 和第三方套件。

【步驟二：風險分類 (Classification)】
   ──→ 對照法案：是不是高風險（醫療診斷、人資篩選、信用貸款）？
        是不是有限風險（聊天機器人、生成圖片）？

【步驟三：高風險合規檢查（若屬於高風險）】
   ──→ 檢查：有沒有「人工監督」機制？資料有沒有去識別化？
        有沒有做網路安全紅隊測試？是否要在歐盟資料庫登記？

【步驟四：持續監控 (Continuous Monitoring)】
   ──→ AI 不是上線就拍拍屁股沒事。只要模型有重大更新，
        就必須重新進行合規與漂移評估。

🔑 模擬題解析

Q: 某家軟體公司開發了一款 AI 影像生成工具，讓使用者可以一鍵把照片轉換為逼真的藝術合成照。根據歐盟 AI 法案（EU AI Act），該公司在將此工具投放市場時，必須遵守以下哪項合規義務？

A. 建立涵蓋整個生命週期的風險管理系統
B. 確保輸出內容有明確的 AI 生成標記（透明度義務）
C. 向歐盟 AI Office 註冊模型算力
D. 實施差分隱私

【正確答案】B

【解析】

• 抓解題關鍵字：AI 影像生成工具、藝術合成照（AIGC）。
• 分析：影像生成、合成圖（AIGC / Deepfake）在法案中被歸類為**有限風險（Limited Risk）**級別。
• 這類系統不屬於高風險（所以不需要做 A 建立繁瑣的風險管理系統），也不屬於大模型源頭（所以不用做 C 去註冊算力），但它最核心的義務就是透明度義務（B），必須在輸出端用浮水印或元資料標記這內容是 AI 畫的，防止誤導。所以選 B。

🎯 今日學習筆記重點

• 有限風險核心：透明度義務。AI 聊天機器人要告知、AI 生成內容要打**浮水印（Watermarking）**或安全元資料（Metadata）標記。
• 最小風險：幾乎不管（遊戲 AI、垃圾郵件過濾、推薦系統）。
• 通用 AI 模型（GPAI）：所有廠商都要公開訓練資料摘要與說明書；算力大於 $10^{25}$ FLOPS 的巨頭模型（系統性風險）還要強制進行對抗性測試與紅隊評估。
• Provider（提供者）與 Deployer（部署者）：大模型大廠只負責源頭，一旦下游將其用在「高風險用途」，部署者（我們）必須承擔全部的高風險合規義務。
• 企業合規步驟：盤點 → 分類 → 執行高風險檢核 → 持續監控。

明天我們要講另一個在合規和實務中非常常考、也是美國政府推薦的 AI 安全與風險管理框架：NIST AI RMF！
我們明天見啦！